BDE, dbExpress, ADO a ostatni

Otázka od: LUKES Václav

4. 9. 2002 13:12

Ahoj,

divam se na debatu ohledne pouzivani BDE, dbExpress a pod. Zajimaly by me Vase
nazory k tomuto tematu.
Predstavte si, ze mate rozsahlou databazi v Oracle nebo Informixu. je lepsi
dvou nebo viceurovnova architektura ??? Je vhodnejsi pouzit dbExpress nebo ADO
???

V.

Odpovedá: Lstiburek Pavel

4. 9. 2002 19:53

Myslim si, ze tri a vice urovnova architektura je obecne vhodnejsi. Pokud se
nejedna o trivialni ulohy je vyhodne oddelit minimalne uzivatelsky
interface, obchodni logiku a praci s daty (manipulace a "uskladneni").
Paradoxne se aplikace vetsinou vyrazne zjednodusi, zprehledni a mnohem lepe
udrzuje. Problemem je, ze se musi provest analyza, coz zdrzuje a ze aplikace
vznika zdanlive velmi pomalu a potom, najednou, zacne (nebo taky ne) vsechno
(nebo aspon skoro vsechno) pracovat.
Strasne zavisi na kvalite zadani, ktere je mozno z uzivatelu vyrazit(a
analyzy, ale tu muzete vetsinou zblnout sami). Pokud se vse dodela a
pripominky jsou typu "my jsme mysleli, ze to zkusime a pak uvidime ..."
vedou casto k rozsahlym upravam a ono nic stale nepracuje (nebo skoro nic) a
.... . Proto jen malo sefu slysi na tuto architekturu (uz jste ve treti
ctvrtine projektu a furt se nic netestuje ... ?). Nebo si viceurovnovou
architekturu vysvetluji jako "tenkeho klienta", ale ten se da napsat (a
casto i je) pouze jako dvouurovnovy (prohlizec je tam sice 3. vrstvou, ale
na te se nic nedeje !), pripominajici terminal-server architekturu 70 let.

Pavel

-----Původní zpráva-----
Od: LUKES Václav [mailto:lukes@ans.cz]
Odesláno: 4. září 2002 14:07
Komu: delphi-l@clexpert.cz
Předmět: BDE, dbExpress, ADO a ostatni


Ahoj,

divam se na debatu ohledne pouzivani BDE, dbExpress a pod. Zajimaly by me
Vase nazory k tomuto tematu.
Predstavte si, ze mate rozsahlou databazi v Oracle nebo Informixu. je lepsi
dvou nebo viceurovnova architektura ??? Je vhodnejsi pouzit dbExpress nebo
ADO ???

V.

Odpovedá: David Janko

4. 9. 2002 18:42

Zdravim,
nevim jak nad jinymi SQL servery, ale nad mysql je dbExpress pro me
nepouzitelnej - a to to nejsou aplikace nejak moc narocne na transakce,
hlidani ref. integrity atd. - uplne mi stacili elementarni problemy s
autoincrementy, typy poli a apod.. Nekde v archivu je muj mail kde sem
problemy na ktere jsem tehdy narazil vypsal podrobne jestli mate zajem
(tusim konec minuleho roku).
Nyni pouzivam ZEOS komponenty pro mysql - i k nim mam par vyhrad, ale je to
pouzitelne.

BDE je mrtve a pouzil bych ho tak max. na malou jednoucelovou utilitu, ktera
se nema dal rozvijet (napr. export dat ze stareho dbf based systemu do
noveho).

ADO tedka zkousim nad MDB a zatim jedinny problem na ktery sem narazil je
nefunkci sort/filtr nad lookup poli - ale je to lokalni file based DB a ne
"normalni" sitove reseni nad SQL serverem.

toliko ma zkusenost ...

---
Best Regards,
                        David Janko
                        programmer & Linux system administrator
                        djanko@infoware.cz
                        +420 604 164 999


----- Original Message -----
From: "LUKES Václav" <lukes@ans.cz>
To: <delphi-l@clexpert.cz>
Sent: Wednesday, September 04, 2002 2:07 PM
Subject: BDE, dbExpress, ADO a ostatni


Ahoj,

divam se na debatu ohledne pouzivani BDE, dbExpress a pod. Zajimaly by me
Vase nazory k tomuto tematu.
Predstavte si, ze mate rozsahlou databazi v Oracle nebo Informixu. je lepsi
dvou nebo viceurovnova architektura ??? Je vhodnejsi pouzit dbExpress nebo
ADO ???

V.

Odpovedá: Slavek Rydval

5. 9. 2002 20:29


Ahoj,

> Problemem je, ze se musi provest
> analyza, coz zdrzuje a ze aplikace vznika zdanlive velmi pomalu a
> potom, najednou, zacne (nebo taky ne) vsechno (nebo aspon skoro
> vsechno) pracovat.
*****Opravdovy problem je, kdyz analyza u strednich a velkych
projektu chybi. Jinak aplikace zacne fungovat cela najedou jen v
pripadech nektereho modelu vyvoje software (napr. tzv. vodopad).
Ovsem v pripade iteracniho vyvoje dostavas neustale (napr. jednou
tydne) dalsi a dalsi fukcnost, coz ma dalsi efekty jako napr. ze
muzes zacit skolit drive, nez prijde ostra verze apod.

Slavek
 
> Pavel
--------------------------------------------------------
http://atrey.karlin.mff.cuni.cz/~rk
Pozor, nyni pouze http://195.113.18.111/~rk/index.shtml
--------------------------------------------------------
Udelejte to blbuvzdorne a zitra nekdo vymysli jeste vetsiho blba.

Odpovedá: Marek Eichler

5. 9. 2002 8:53

Zdravim,

> *****Opravdovy problem je, kdyz analyza u strednich a velkych
> projektu chybi. Jinak aplikace zacne fungovat cela najedou jen v
> pripadech nektereho modelu vyvoje software (napr. tzv. vodopad).
> Ovsem v pripade iteracniho vyvoje dostavas neustale (napr. jednou
> tydne) dalsi a dalsi fukcnost, coz ma dalsi efekty jako napr. ze
> muzes zacit skolit drive, nez prijde ostra verze apod.
**** Uz jsem to videl nekolikrat, takze se chci zeptat. Jake jsou typy
vyvoje SW a kde o tom mohu ziskat informace?

> Slavek

S pozdravem Marek Eichler

Odpovedá: Jan Sebelík

5. 9. 2002 18:27

> Komu: delphi-l@clexpert.cz
> divam se na debatu ohledne pouzivani BDE, dbExpress a pod. Zajimaly by me
Vase nazory k tomuto tematu.
> Predstavte si, ze mate rozsahlou databazi v Oracle nebo Informixu. je lepsi
dvou nebo viceurovnova architektura ??? Je vhodnejsi pouzit dbExpress nebo ADO
???

Moznych reseni je cela rada.

Kdyz se tady ale mluvilo o nativnich komponentach, tak proc ne vicevrstva
architektura a na aplikacnim serveru TORADataSet.
Vyzkouseno, funguje jako z praku.

Honza Sebelik
=========================================
= HAES - RNDr. Jan Sebelik
= http://www.haes.cz
= Skolici a konzultacni stredisko pro Delphi a Win32
= Vojtiskova 206
= 507 81 Lazne Belohrad
= tel. 0434 692 569 (0776 347735)
=========================================

Odpovedá: Lstiburek Pavel

7. 9. 2002 20:24

> Od: Slavek Rydval [mailto:rk@atrey.karlin.mff.cuni.cz]
> Ahoj,
>
> > Problemem je, ze se musi provest
> > analyza, coz zdrzuje a ze aplikace vznika zdanlive velmi pomalu a
> > potom, najednou, zacne (nebo taky ne) vsechno (nebo aspon skoro
> > vsechno) pracovat.
> *****Opravdovy problem je, kdyz analyza u strednich a velkych
> projektu chybi. Jinak aplikace zacne fungovat cela najedou jen v
> pripadech nektereho modelu vyvoje software (napr. tzv. vodopad).
> Ovsem v pripade iteracniho vyvoje dostavas neustale (napr. jednou
> tydne) dalsi a dalsi fukcnost, coz ma dalsi efekty jako napr. ze
> muzes zacit skolit drive, nez prijde ostra verze apod.
>
> Slavek
>
Psal jsem to v ponekud sarkastickem tonu (sorry), ale podle mych zkusenosti
je pro tri- a vice-urovnovou aplikaci mozno paralelne pracovat
prakticky na vsech vrstvach najednou. Proto jsem psal, ze to zacne
"fungovat"
vsechno skoro "najednou".
My jsme "paralelni" vyvoj realizovali prostrednictvym
predbeznych specifikaci rozhrani vrstev a objektu.
Byly navrzeny property a metody objektu jednotlivych vrstev
a bez toho, ze by byly naprogramovany, se zacaly pouzivat.
Prace jde (z hlediska programatoru) hezky od ruky,
funkcionalita metod se da vesmes snadno nasimulovat a tak si odladit
i slozite chovani, ale stale neni nic co lze predvest uzivateli
(predpokladam,ze ten jiz navrh interface uz schvalil).
Pri prvnim pouziti teto metody nam predani prvniho plne funkciho formulare
k testovani uzivatelum trvalo skoro 3 mesice (vsechny vrstvy byly plne
funkci).
Druhy byl hotov ve stejny den odpoledne. Pak jsme to uz ani memerili.
Moc hezky se odstranuji chyby: malickosti jsou vesmes v interface a cim
vaznejsi chyba tim spise je nekde v nizsich vrstvach a je spolecna pro vice
formularu, rychle se zjisti, ....
Faktem je, ze pokud je nekdo zvykly na odskrtavani "hotovych" vystupu
a chce se radovat jak to pekne hraje s "planem", tak pro nej je tento postup
rovnou
na infakt = "Na vsem se pracuje, vsechno "skoro" funguje a nic poradne".

Pavel